Build/Analyze ignore package compatibility #43829
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
scbedd
changed the title
This was referenced Nov 5, 2025
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a new --disable-compatibility-filter flag to control package compatibility filtering during package discovery in CI/CD pipelines. The flag allows static analysis checks (pylint, mypy, pyright, black, bandit, breaking changes, and verification tasks) to run on all packages regardless of Python version compatibility.
Key changes:
- Added
--disable-compatibility-filtercommand-line argument to dispatch scripts - Modified pipeline YAML files to use the new flag for static analysis and verification steps
- Changed
build.pyto explicitly disable compatibility filtering (hard-coded toFalse)
Reviewed Changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| scripts/devops_tasks/dispatch_tox.py | Added --disable-compatibility-filter argument with logic to control compatibility filtering based on filter type and new flag |
| eng/tools/azure-sdk-tools/ci_tools/build.py | Changed compatibility_filter from True to False for build package discovery |
| eng/scripts/dispatch_checks.py | Added --disable-compatibility-filter argument with same logic pattern as dispatch_tox.py |
| eng/pipelines/templates/steps/run_pyright.yml | Added --disable-compatibility-filter flag to pyright and verifytypes commands |
| eng/pipelines/templates/steps/run_pylint.yml | Added --disable-compatibility-filter flag to pylint check command |
| eng/pipelines/templates/steps/run_mypy.yml | Added --disable-compatibility-filter flag to mypy check command |
| eng/pipelines/templates/steps/run_breaking_changes.yml | Added --disable-compatibility-filter flag to breaking changes check command |
| eng/pipelines/templates/steps/run_black.yml | Added --disable-compatibility-filter flag to black check command |
| eng/pipelines/templates/steps/run_bandit.yml | Added --disable-compatibility-filter flag to bandit check command |
| eng/pipelines/templates/steps/analyze.yml | Added --disable-compatibility-filter flag to verifysdist, verifywhl, and verify_keywords commands |
lmazuel
approved these changes
Nov 6, 2025
|
/check-enforcer evaluate |
mccoyp
approved these changes
Nov 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context. I'm trying to unblock #43771 . In that PR, there is a package that does not support
3.9. We build onpython 3.9. By default, our common package discovery function will filter packages that are not compatible with the running interpreter. This means that the package in #43771 isn't compatible with build, which is obviously a blocker.The devs on that PR rightly identified that they could override the
TEST_COMPATIBILITY_MAPto FORCE the common discovery to find their package, but are now blocked on the fact that the package is incompatible with python 3.9 but still running on 3.9 because of their override of theTEST_COMPATIBILITY_MAPto build the package.To address their issue, I am making
buildandanalyzephases totally ignore the running interpreter as far as filtering packages during discovery. I'm doing that by adding a new parameter where one wasn't necessary before.Once this PR merges, #43771 will merely need to remove their
TEST_COMPATIBILITY_MAPchanges and should be unblocked.Verification builds: